The present invention relates to distributed computing, and in particular, to systems and methods of accessing information across distributed computing components, such as software services.
With the ever increasing demand for software functionality, the size of software programs continues to grow. Historically, software programs were written as large monolithic blocks of code that could be compiled and executed as a single unit. However, as programs grew in size, distributed computing architectures became more prevalent. In a distributed computing architecture, a program may be divided into components, each of which may implement some particular functionality of the program. FIG. 1 illustrates a distributed computing architecture. In FIG. 1, a software program 100 includes numerous software components A-H. The software components may interoperate in a variety of ways to define the overall behavior of the program. In many instances, particular software components may require inputs from other components to perform their functions. For example, software component A 102 may require inputs from software component B 104 to implement its functionality. Similarly, software component B 104 may receive inputs from software components C, D, and E to implement its functionality. Likewise, software component C 110 may require inputs from software component F 120 and software component G 122, and software component D 112 may require input from software component H 130. This example illustrates that the operation of software component A may depend directly on the behavior of another component B that provides direct inputs to component A. Moreover, the operation of component A may depend indirectly on the behavior of other components C-H that provide inputs to component B (directly or indirectly), which is providing an input to component A.
In many instances, it is desirable for component A to obtain information about other components that are providing inputs to component B. For example, in some applications it may be desirable for component A to obtain information that describes various aspects of downstream components C-H. In one embodiment, the present invention provides a technique for a software component to obtain information about other software components in the system that indirectly provide inputs to such software component.
An illustrative example of the shortcomings of traditional distributed computing techniques is the area of software services. With the ever increasing demand for software features, many companies are embracing the use of software as a service. Traditionally, software was sold on CDs in shrink-wrapped boxes or as installer files downloadable from a Web site. The software was then installed on a system controlled by the customer and operated under the authority of the customer. In contrast, with software services, customers no longer buy software that they can install and run. Rather, a customer may buy the right to use a piece of software running on a system operated by a third party. In many applications, software services operated by third parties use other software services operated by yet other parties. Thus, software services are an example of a distributed computing architecture.
FIG. 2 illustrates a typical configuration of distributed software services. An application component 201 may use a software service component 203 during operation. Accordingly, component 201 may make “requests” to service component 203. However, before the requestor 201 may send its request, the requestor may be required to know certain information about the software service 203. Typically, software services make certain information that describes the service available to applications using the service. For example, some software components or services may only expose an interface for using the component or service, while hiding the implementation of the component or service. Thus, some components or services may be seen as a black box that can only be accessed through a certain interface. In practice, the only thing that a provider needs to communicate to the consumer is a set of technical artifacts that document how to access the service. These technical artifacts, which may be stored as metadata, often play the role of a limited form of “interaction contract” between the service provider and the service consumer. One example of such metadata is a service interface (i.e. which functionalities are offered by the service provider along with documents detailing how to call them and which data formats should be used for communication). Referring to the example in FIG. 2, service 203 may expose metadata 205 so that requestor component 201 can request the metadata 205. After receiving metadata 205, requestor 201 may send a job to software service 203 for execution and receive back results that may act as inputs to the requester application.
In some systems, service component 203 may further use the resources of other service components, such as components 207 and 211, to perform their functions. For example, as an application in service A is processing the request from the requestor 201, it discovers that it needs to contact service providers service B 207 and service C 211 for their services. Service A requests and receives service B's metadata 209 and service C's metadata 213 in a similar manner as the requester received the metadata from service A above. After receiving the metadata, service A sends jobs to service B and service C. Service B does not consume any services so it does not require any services to complete its job. After completing its job, service B sends a response back to service A. Service C, on the other hand, uses service D 215. Thus, service C requests and receives service D's metadata 217. After the exchange, service C sends a job to service D. Like service B, service D does not require any services to complete its job. Service D completes its job and sends a response back to service C. After receiving the response from service D, service C is now able to complete its job. Service C then sends a response to Service A. Now that Service A has all the information necessary to complete the request, it finishes its job and sends a response to the requestor 201.
One problem with existing distributed computing technologies is that the components in the system have no efficient formal mechanism for sharing information between indirectly related components. In the context of software services, there is currently no efficient mechanism by which requestor services can obtain information that describes services that are used indirectly to process jobs. Accordingly, users of software services lose visibility and control over how some parts of their software are executed. In some cases, software service users may want to inspect how the service handles the protection and privacy of their confidential data, for example, and may want to audit all components used directly and indirectly in processing data. Unfortunately, there is currently no formal mechanism for auditing indirect software services.
Thus, there is a need for improved mechanisms for accessing information about components in a distributed computing environment. The present invention solves these and other problems by providing improved systems and methods of accessing information across distributed computing components.